docs: remove retired legacy RPCs - #65

Hand-edited auto-generated config

Medium Severity

The enabled_legacy_sei_apis cleanup edits comments and allowlist entries inside the AUTO-GENERATED:APP_TOML block. That block is replaced wholesale by scripts/sync-default-configs.mjs from seid init output, so hand-written changes are clobbered on the next sync and can drift from the real defaults. This violates the rule against hand-editing inside AUTO-GENERATED config blocks.

 

^{Triggered by learned rule: Do not hand-edit inside AUTO-GENERATED config blocks}

^{Reviewed by Cursor Bugbot for commit 3b93eb7. Configure here.}

[suggestion] This states the removal in the present tense with no release boundary. The docs previously used version markers for exactly this case ("removed in v6.6.0 (#3618)"), which this rewrite drops everywhere. Operators and integrators on current binaries still have sei2_* and the other methods, so as written this page is wrong for them. Suggest "removed in vX.Y.Z" once the sei-chain release is known, and link the release notes rather than an open PR — a PR link will read as "not shipped yet" to anyone who follows it, and as dead context after it merges.

[suggestion] This sample is presented as the node's verbatim error output, and the change rewrites it by hand (The sei_* and sei2_* JSON-RPC surfaces are deprecated → The sei_* JSON-RPC surface is deprecated, plus swapping the method name). Same applies to the header value on line 1490 and the app.toml comment block in node/node-operators.mdx:435-445. If sei-chain #3927 does not make the identical wording change, all three drift from what the node actually emits — worth diffing them against the chain PR before merge, since readers may be string-matching on them.

[suggestion] This tells the reader to use sei_getTransactionReceipt "if you already know a synthetic transaction hash" but never says how to obtain one now that sei_getLogs, sei_getBlockByNumber, and the sei_* filter methods are gone. That leaves the advice unusable in practice. Please point at the actual discovery path (CometBFT tx search / block events / an indexer) or say plainly that synthetic-log discovery over JSON-RPC is no longer supported — either is more useful than an unreachable precondition.

[suggestion] This section now documents only the EVM → Cosmos direction. The inverse, sei_getEvmTx (Cosmos → EVM hash), is removed by this PR with no replacement mentioned anywhere in the docs, even though the section title still promises "cross-VM transaction lookup" generally. Add a sentence on what integrators should do for the reverse mapping, or note explicitly that it has no replacement.

[nit] The authoritative method list now sits under ### Legacy API configuration, after the TOML block, which makes it hard to find from the section heading. Consider moving it up under ## Sei custom endpoints next to the "four legacy custom endpoints" sentence it supports. Separately, sei_getCosmosTx gets a full parameters/result/example subsection while sei_getTransactionReceipt — the one method that is off by default and therefore needs the most explanation — only appears as a table row.

[nit] Since the documented result type changes here from object to a bare string, an Example Response block alongside the existing request example would make the new contract unambiguous — the uppercase-no-0x format is easy to get wrong when migrating.

[suggestion] The Parameters: block was dropped here, but every other command in this file keeps one (see Send Native Tokens below). The bracket notation implies [custom-message] is optional, yet the example always passes "associate" and the prose does not say what happens if it is omitted or what the value is used for. Please restore a short parameters list stating whether it is optional and what a caller should put there.

[suggestion] This contradicts the Common Transaction Flags section above (line 30: "All transaction commands support these common flags", including --evm-rpc) and the <Info> at line 26. Worth qualifying that list — e.g. "all EVM-RPC transaction commands" — so the two statements do not conflict on the same page.

[nit] These two headings are switched to sentence case while every other heading in the file stays Title Case (## Overview, ## Network Configuration, ## Common Transaction Flags, ## Token Transfer Commands at line 61, ### Send Native Tokens). Either leave them as-is or convert the whole file in a follow-up — a two-heading conversion just makes the page look inconsistent.

[suggestion] The replacement note drops the "gasless" characterization the old text carried. That was the operative property for this flow: sei_associate broadcast a no-gas AssociateTx, whereas the addr precompile path is a regular EVM transaction requiring a funded account — which is precisely the situation an unassociated user is often in. "Method 3 provides the same wallet-signed-message flow" is true for the signing UX but glosses over that funding requirement. Worth one clause spelling out the difference.